We bump our `vss-client` dependency to include the changes to the
`StorableBuilder` interface.

Previously, we the `vss-client` didn't allow to set `ChaCha20Poly1305RFC`'s `aad` field,
which had the `tag` not commit to any particular key. This would allow a
malicious VSS provider to substitute blobs stored under a different key
without the client noticing.

Here, we now set the `aad` field to the key under which the `Storable`
will be stored, ensuring that the retrieved data was originally stored
under the key we expected.

We also account for `StorableBuilder` now taking `data_decryption_key`
by reference on `build`/`deconstruct`.

We previously attempted to drop the internal runtime from `VssStore`,
resulting into blocking behavior. While we recently made changes that
improved our situation (having VSS CI pass again pretty reliably), we
just ran into yet another case where the VSS CI hung (cf.
https://github.com/lightningdevkit/vss-server/actions/runs/19023212819/job/54322173817?pr=59).

Here we attempt to restore even more of the original pre-
ab3d78d / lightningdevkit#623 behavior to get rid of
the reappearing blocking behavior, i.e., only use the internal runtime
in `VssStore`.

Now that we rely on `reqwest` v0.12.* retry logic as well as client-side
timeouts, we can address the remaining TODOs here and simply drop the
redundant `tokio::timeout`s we previously added as a safeguard to
blocking tasks (even though in the worst cases we saw they never
actually fired).

To avoid any blocking cross-runtime behavior that could arise from
reusing a single client's TCP connections in different runtime contexts,
we here split out the `VssStore` behavior to use one dedicated
`VssClient` per context. I.e., we're now using two
connections/connection pools and make sure only the `blocking_client` is
used in `KVStoreSync` contexts, and `async_client` in `KVStore`
contexts.